Evidently it is still possible to fail here:

https://github.com/d-w-moore/python-irodsclient/blob/388ad3d858ebcc7be981d1c065a4dd57ffc066cf/irods/test/data_obj_test.py#L3317

The modify time turned out on this occasion to be one second later than the access time on a just-created replica open for write:

======================================================================
FAIL [0.216s]: test_access_time__issue_700 (data_obj_test.TestDataObjOps.test_access_time__issue_700)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/prc.rw/irods/test/data_obj_test.py", line 3317, in test_access_time__issue_700
    self.assertEqual(data.access_time, data.modify_time)
    ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: datetime.datetime(2025, 11, 29, 4, 12, 23, tzinfo=datetime.timezone.utc) != datetime.datetime(2025, 11, 29, 4, 12, 24, tzinfo=datetime.timezone.utc)

----------------------------------------------------------------------
Ran 302 tests in 319.841s

FAILED (failures=1, skipped=16)

@korydraughn any ideas why this might occasionally happen?

Squashed , ready for review.

Evidently it is still possible to fail here:

https://github.com/d-w-moore/python-irodsclient/blob/388ad3d858ebcc7be981d1c065a4dd57ffc066cf/irods/test/data_obj_test.py#L3317

The modify time turned out on this occasion to be one second later than the access time on a just-created replica open for write:

======================================================================
FAIL [0.216s]: test_access_time__issue_700 (data_obj_test.TestDataObjOps.test_access_time__issue_700)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/prc.rw/irods/test/data_obj_test.py", line 3317, in test_access_time__issue_700
    self.assertEqual(data.access_time, data.modify_time)
    ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: datetime.datetime(2025, 11, 29, 4, 12, 23, tzinfo=datetime.timezone.utc) != datetime.datetime(2025, 11, 29, 4, 12, 24, tzinfo=datetime.timezone.utc)

----------------------------------------------------------------------
Ran 302 tests in 319.841s

FAILED (failures=1, skipped=16)

@korydraughn any ideas why this might occasionally happen.

Hmm, I don't think the python test code is equivalent to the following C++ test code?

https://github.com/irods/irods/blob/1a5670d157ce932cc2888d74bb29c831e2db53ae/unit_tests/src/test_rc_update_replica_access_time.cpp#L312-L323

https://github.com/irods/irods/blob/1a5670d157ce932cc2888d74bb29c831e2db53ae/unit_tests/src/test_rc_update_replica_access_time.cpp#L689-L706

The C++ test code I linked to expects the replica to be in the intermediate state.

I think the problem with the python test is that the following call closes the data object, resulting in the close operation updating the mtime.

What you need to do is open (and create) a new replica and do your checks while the replica is open. Closing the replica is what causes the atime and mtime to desync.

What you need to do is open (and create) a new replica and do your checks while the replica is open. Closing the replica is what causes the atime and mtime to desync.

Ah, you're right. I see. Will try it a different way.

What's the status of this PR?

What's the status of this PR?

Looks like we are good. Need a squash, and perhaps a codacy review.

To this subject
We can now , in this PR, do the following :

d_bin_meta = d.metadata(iRODSMeta_type = iRODSBinOrStringMeta)
d_bin_meta.set ( 'key1', b'arbitrary-octets-\xe1\x80')

And later: d_bin_meta ['key1'] (or an object similarly conditioned, in another application perhaps ) automatically returns an iRODSBinOrStringMeta('key1',b'arbitrary-octets-\xe1\x80') AVU

At worst, it's the client lib doing too much.

At best, it smooths a path that Python2 folks hypothetically might have relied on in the past (since bytestrings and strings were the same back then).

I see a revert in the git history?
Was that planned/expected?

What's the status of this PR?

I see a revert in the git history?
Was that planned/expected?

The revert was merely to remove an unrelated change, a commit that shouldn't have made it in....

Squashed just now.

Okay. Please resolve the ruff-check/format reports.

The "Files Changed" page (diff) should highlight the lines reported by the ruff workflows. You can use that view with the github actions report.